Within a message delivery system, messages may be delivered through a network of servers including one or more “brokers” which provide routing and formatting services. The brokers are located at communication hubs within the network.
Many message brokers support the publish/subscribe communication paradigm. This involves a set of one or more publishers sending communications to be received by a set of one or more subscribers who have registered their interest in receiving communications of that type. Publish/subscribe allows subscribing users to receive the very latest information in an area of interest (for example, stock prices or events such as news flashes or store special offers). A typical publish/subscribe environment has a number of publisher applications sending messages via a broker to a number (potentially a very large number) of subscriber applications located on remote computers across the network. In this case, the subscribers notify the broker(s) of the message types they wish to receive and this information is stored at the broker. Publishers send their messages to the broker, which uses a matching engine to compare the message type (for example, checking message header topic fields and/or checking message content) with its stored subscriber information to determine which subscribers the message should be forwarded to. The message broker may perform additional functions, such as filtering, formatting or otherwise processing received messages before forwarding them to subscribers.
A commercially available example of a message broker supporting the publish/subscribe paradigm is IBM Corporation's WebSphere MQ Integrator middleware product family. (IBM and WebSphere are trademarks of International Business Machines Corporation).
Existing publish/subscribe solutions (including IBM's WebSphere MQ Integrator products) provide a security authorization feature that permits publications to be accepted or refused by reference to the specific publisher and topic, and permits their dissemination to be controlled by reference to the set of subscribers authorized to receive messages for that topic. Such authorizations will be set up by an administrator and act in conjunction with the topic subscriptions made by the subscribers themselves.
U.S. Pat. No. 6,158,007 discloses a broker enforcing security policies for different subjects, and an audit service subscribing to a publish/subscribe matching engine to receive messages on specific subjects. The audit service can be thought of as one of the subscribers, since the audit service will receive the original message if the message subject matches a specific list of subjects stored at the broker. A problem with this approach is that the publish/subscribe paradigm normally only allows a subscriber to receive a message which matches its subscription profile, without knowing which other subscribers received the message.
Infosafe from icc.net is a publishing management service which keeps an audit trail for publish/subscribe activity—including a complete audit trail of all product based activity and reports of all upload and download activity by client and product.
David Arnold et al, “Discourse with Disposable Computers: How and Why You Will Talk to Your Tomatoes”, USENIX Proceedings of the Embedded Systems Workshop, Mar. 29-31 1999, Cambridge, Mass., USA, describes a prototype message routing program, known as Elvin, which provides content-based routing and security based on authorization keys. Arnold et al recognize the need for charging for publish/subscribe services, but the only solution mentioned is charging based on the number of bytes of data exchanged.
There remains a need in the art for improved publish/subscribe systems, in which features such as auditing, charging and/or security are not limited as in the above-referenced examples.